Hi, I need to find a way to identify the execution context of DXL file launched normally (i.e. not in the startup)? Any idea ?
a response to that could be solution element for https://www.ibm.com/developerworks/community/forums/html/topic?id=81553c21-e246-46fd-8196-78fc331b7236
Thanks for your help. jaracic - Tue May 30 04:17:28 EDT 2017 |
Re: Unique dxl context idenfication You can parse the dxlHere() output to get the file. In case of relative include you only get a path relative to the include path. Therefore you need to find the right file, by combining the output of dxlHere with the include path. I did this in the parallels library. See the "getCurrentFile" function here: https://github.com/domoran/DXLParallels/blob/master/lib/core/System.inc Maybe that helps, regards, Mathias |
Re: Unique dxl context idenfication Mathias Mamsch - Tue May 30 08:38:55 EDT 2017 You can parse the dxlHere() output to get the file. In case of relative include you only get a path relative to the include path. Therefore you need to find the right file, by combining the output of dxlHere with the include path. I did this in the parallels library. See the "getCurrentFile" function here: https://github.com/domoran/DXLParallels/blob/master/lib/core/System.inc Maybe that helps, regards, Mathias Thank you Mathias, Obviously I was not clear enough. I would like to find out a way to obtain a unique ID (at least within the context of a DOORS session) that identifies the execution of a DXL script.
For example, I would like to have a "string getDXLExecID()" that returns each time I call it the same value in the script but a different value for each execution of this script (at least for the DOORS session) EVENT iF THEY ARE EXECUTED in parallel (different GUI instances).
I hope it is clearer. I would like also to say why I need that : I would like to store at the top level in a Skip list a function address that is not in a top level context.
|
Re: Unique dxl context idenfication jaracic - Thu Jun 01 03:33:30 EDT 2017 Thank you Mathias, Obviously I was not clear enough. I would like to find out a way to obtain a unique ID (at least within the context of a DOORS session) that identifies the execution of a DXL script.
For example, I would like to have a "string getDXLExecID()" that returns each time I call it the same value in the script but a different value for each execution of this script (at least for the DOORS session) EVENT iF THEY ARE EXECUTED in parallel (different GUI instances).
I hope it is clearer. I would like also to say why I need that : I would like to store at the top level in a Skip list a function address that is not in a top level context.
I am not sure, you need what you wrote above. If you say "DOORS session", that registers to me as a DOORS client process. If you need a function that can differentiate between clients I think you would need the process ID of the DOORS process (theres a post for that), but that has nothing to do with storing whatever in the global context, since two DOORS processes running DXL in parallel cannot influence each other at all (they can, but that is another page). So I don't think you are talking about DOORS sessions, but rather about two DXL scripts being executed inside DOORS "in parallel" (note that DXL is single threaded, so there is no real parallel execution), but one DXL can have data loaded in the global DXL context, or be waiting inside the event loop of the DOORS client (e.g. trigger, gui, DXL layout, DXL attribute) while the other is executed through the menu or through "Edit DXL". Now I understand you want to call a function inside the global context or another waiting DXL context from the currently running DXL. That is possible but very risky and it needs to be restricted in a way to avoid, that you store volatile data of the running DXL (strings, arrays, any allocated object) inside the global context, because after the DXL ends, all these resourced will be freed except if you force the "child" context to stay alive. Soo ... I would like to step up here one or two steps and ask you: Why would you need a risky thing like that? What is the DXL Program supposed to be doing, that you are trying to develop ? Regards, Mathias |
Re: Unique dxl context idenfication Mathias Mamsch - Thu Jun 01 03:51:36 EDT 2017 I am not sure, you need what you wrote above. If you say "DOORS session", that registers to me as a DOORS client process. If you need a function that can differentiate between clients I think you would need the process ID of the DOORS process (theres a post for that), but that has nothing to do with storing whatever in the global context, since two DOORS processes running DXL in parallel cannot influence each other at all (they can, but that is another page). So I don't think you are talking about DOORS sessions, but rather about two DXL scripts being executed inside DOORS "in parallel" (note that DXL is single threaded, so there is no real parallel execution), but one DXL can have data loaded in the global DXL context, or be waiting inside the event loop of the DOORS client (e.g. trigger, gui, DXL layout, DXL attribute) while the other is executed through the menu or through "Edit DXL". Now I understand you want to call a function inside the global context or another waiting DXL context from the currently running DXL. That is possible but very risky and it needs to be restricted in a way to avoid, that you store volatile data of the running DXL (strings, arrays, any allocated object) inside the global context, because after the DXL ends, all these resourced will be freed except if you force the "child" context to stay alive. Soo ... I would like to step up here one or two steps and ask you: Why would you need a risky thing like that? What is the DXL Program supposed to be doing, that you are trying to develop ? Regards, Mathias Hi,
Yes, but this function is a virtual one and the concrete one is in the currently running DXL context see https://www.ibm.com/developerworks/community/forums/html/topic?id=81553c21-e246-46fd-8196-78fc331b7236#repliesPg=0
It would be long to explain (technical debt ...) But it is not risky because the the concrete function don"t store data at all... regards. Joseph. |